在前幾篇文章中介紹了用 materialization 和 macro 這兩種方式在 dbt 上實作 UDF，那就來回顧及統整兩種實作方式，以及比對兩者的優缺點！

實作步驟

用 macro 實作 UDF 需要以下步驟

1. 開發 UDF macro：macro 內為創建 UDF 語法
2. 建立 create_udfs：參數為要創建的 UDF 名稱，macro 內為迴圈執行對應名稱的 UDF macro
3. CI/CD：捕捉有異動的 UDF macro 檔案，並執行 dbt run-operation create_udfs 並傳入異動 UDF 參數

用 materialization 實作則需要以下步驟

1. 建立 UDF materialization：在 macro 資料夾中建立 UDF materialization，並在裡面定義 UDF model 是如何轉為數據庫的 UDF
2. 在 dbt_project.yml 定義 UDF 資料夾對應到數據庫哪個 dataset
3. 開發 UDF model：填寫 config，需要填寫在 materialization 中定義的必填參數，model 中填寫 UDF 要執行的語法

兩種實作方法差異

macro 和 materialization 最大差異就在於 materialization 建立好後，可以使用 model 來開發 UDF，而 model 是 dbt 最核心的項目，有很多功能都是圍繞著 model ，像是可以併發創建 models、models 間可以定義上下游關係等等。

在先前文章中有提到 macro 開發 UDF 有很多缺點，那 materialization 有解決這些缺點嗎？

1. 無法管理 UDF 間的上下游關係 → 使用 model 開發 UDF，就能在 model 中使用 ref 來定義上下游關係，並且可以定義 UDF 和 model 的關係
2. 無法併發創建 UDF → model 可以併發創建
3. 使用 UDF 無法區分環境 → 使用 model 後，便可以使用客製的 get_custom_schema 在 CI 將 UDF 建立在測試環境，並且測試環境的 model 統一會使用測試的 UDF

materialization 除了解決以上缺點外，還有以下的優點：

• UDF 說明可以定義在資料夾的 schema.yml 中，這邊的說明也會在建立 UDF 時同步寫入到 BigQuery UDF 的說明中
• dbt Power User Lineage：在 VScode 有個好用的 dbt 插件叫做 dbt Power User，可以透過此插件觀察 model 間的上下游關係，用 model 開發 UDF 後，就能把 UDF 納入關聯圖當中

但實作 materialization 需要花費較多時間，建立 materialization 需要先了解其中每個步驟的用途、需要花時間參考其他 materialization source code 以及如何修正，還有後續可能的 bug。

我們團隊在建立 UDF materialization 後也有遇到一些 bug，像是我們在 CI 階段時會先用 dbt-dry-run 這個套件檢查 model compile 後的 SQL 語法能否在 BigQuery 上執行，避免到 dbt run 執行大量 model 後才遇到錯誤。

但我們自行建立的 UDF materialization 並沒有包含在 dbt-dry-run 中，所以會無法 dry-run，如果想 dry-run 必須大幅改動套件中的 code，衡量之下我們最後是放棄對 UDF 進行 dry-run（UDF 改動次數少且 UDF 通常為 models 中的最上游）。

總結來說，materialization 比起 macro 的做法更能夠將 UDF 融入在 dbt 中，也具備更多優點；但其在實作上較為困難，也有可能會遇到未預期的錯誤，大家可以自行斟酌哪個方式最適合自己。